log_entries channel of type "email" missing property "body"

#1

Hello,

We are migrating our product from the v1 API to the v2 API.

I am trying to access the full details for an incident triggered by an email, namely the body of said email. In v1, this was done by retrieving the channel for the triggering log_entry. If the channel was of type 'email', then it would have a property called body.

The following documentation indicates that this has not changed:
https://support.pagerduty.com/docs/retrieve-trigger-event-data-using-the-api

However, when I get a log_entry via the v2 API, the only properties on the channel are type ('email') and summary. This is the response from one of the log_entries:

{ log_entry:
   { id: 'Q03T6MX7YXH4F8',
     type: 'trigger_log_entry',
     summary: 'Triggered through email',
     self: %NEW_USER_LINK_REDACTED%,
     html_url: %NEW_USER_LINK_REDACTED%,
     created_at: '2016-06-19T23:37:37Z',
     agent:
      { id: 'PWC8S91',
        type: 'generic_email_inbound_integration_reference',
        summary: 'Email',
        self: %NEW_USER_LINK_REDACTED%,
        html_url: %NEW_USER_LINK_REDACTED% },
     channel:
      { type: 'email',
        summary: %EMAIL_SUBJECT_REDACTED% },
     service:
      { id: 'PHWRN7N',
        type: 'service_reference',
        summary: 'support@stainlesscode.com',
        self: %NEW_USER_LINK_REDACTED%,
        html_url: %NEW_USER_LINK_REDACTED% },
     incident:
      { id: 'P8BG8RW',
        type: 'incident_reference',
        summary: '[#44] %EMAIL_SUBJECT_REDACTED%',
        self: %NEW_USER_LINK_REDACTED%,
        html_url: %NEW_USER_LINK_REDACTED% },
     teams: [],
     contexts: [],
     event_details: { description: %EMAIL_SUBJECT_REDACTED% } } }

Is this bug? If not, how do I go about getting the email body for a particular incident?

Thank you.

#2

Could you please post the request you’re making when you receive that response? That way I can have a better idea of what the issue may be.

#3

Hey Tom,

Thanks for getting back to me.

I use this library to make requests to the API:

The endpoint I am requesting when I get that response is:
log_entries/Q03T6MX7YXH4F8?include[]=channel

This is the code I would run to make that request:

var pdjs = new PDJSobj({
    subdomain: "stainlesscode",
    token: %API_TOKEN_REDACTED%
});

pdjs.api({
  res: "log_entries/Q03T6MX7YXH4F8?include[]=channel"
});

Thanks.

#4

Just following up with a similar issue.

When I fetch a log_entry with a channel of type 'web_trigger' via the v2 API, the channel lacks the documented details property that used to be there in v1. This issue isn’t as mission critical as the missing body property reported above. However, it seems related and it would be nice if I was able to get this info as well.

#5

Hi Joshua,

Thank you for that additional information!

I just wanted to let you know that we received this message from you and we are checking in with our Product Team for some additional help.

Please let us know if you have any further questions in the meantime or if you have any additional information.

Cheers,

#6

Thanks for the update Crystal.

#7

I was able to get the email body in my own account using our instructions here.

It looks like yours didn’t work due to a small typo; it should be channels instead of channel. Here is a sample curl request that I got to work:

curl -X GET --header 'Accept: application/vnd.pagerduty+json;version=2' --header 'Authorization: Token token=xxxxxxxxxxxxxxxx' 'https://api.pagerduty.com/log_entries/R0TLWKUUBVU1UQ3DW4XZXCB2Q5?time_zone=UTC&include%5B%5D=channels'

Hopefully that helps!

#8

Hi Paul,

I can confirm that after updating my request to ue channels instead of channel, I get back the expected info.

As I mentioned, I was migrating from the v1 API to the v2 API. Perhaps the documentation of this feature changed, or at the very least, using channel in the v1 API would return the correct data, while in v2, it returned some data, just not all of it. After further testing, I see that some channel info is returned by default. These things definitely tripped me up into not noticing the difference between my request and the documentation. Not sure if there is anything you can do to make any of that clearer or not.

Thank you very much for the help,

  • Joshua
#9

Glad to hear you were able to get the info you needed – I’ll be sure to pass along your feedback so that we can look into making the documentation clearer.